1. Field of the Invention
The present invention generally relates to electronic document protection. Specifically, the present invention relates to a method, system, and program product for preventing unauthorized changes to an electronic document.
2. Related Art
As the capabilities of information technology continue to improve, documents such as contracts are increasingly being negotiated and executed in an electronic environment. One key aspect of electronic document execution involves the use of digital signatures. As convenient as they can be, digital signatures raise a variety of issues specifically where execution by multiple parties is required (e.g., in contracts). These issues range from technology-based issues such as whether the particular language in which the document is provided can support multiple signers) to security-based issues such as whether a portion of the document that is already executed by one party can be protected against unauthorized changes by another party.
One more recent technology used for electronic documents/forms is known as XForms. Specifically, traditional HTML Web forms don't separate the purpose from the presentation of a form. XForms, in contrast, are comprised of separate sections that describe what the form does, and how the form looks. This allows for flexible presentation options, including classic XHTML forms, to be attached to an XML form definition. However, current web form solutions based on XForms do not incorporate digital signatures. Prior approaches fail to address this problem because they do not support partial data signing, and fail to address the interaction of signature information on presentation layer constructs. In addition, prior Extensible Forms Description Language (XFDL) releases that have supported multiple signer scenarios are based on signature filters that operate directly over the presentation layer constructs. To this extent, the signature status of presentation layer constructs was used to determine the signature status of data items/nodes associated with user interface constructs/bindings (UICs). Unfortunately, since this strategy is not data-centric, it causes the unnecessary omission of presentation layer details from the signature, rather than conveniently restricting omission to the actual data items that a user is authorized to change after a first signature is applied. Still yet, this technique fails for hierarchical UICs that contain a template of other form controls to be generated one or more times, or to be conditionally generated.
In addition, many document formats support dynamic behaviors during document rendition using some kind of scripting language, such as JavaScript. However, to be considered as an effective document format for archival and digital signature security purposes, the scripting support must either be disabled or not used. For example, one well known document format disables scripting in order to be an acceptable archival format. A second example occurs when a user attempts to digitally sign a form that includes JavaScript. In this case, the user is treated to a disturbing and serious sounding warning that indicates the signature may be insecure because the form includes JavaScript. Since, the user has no way of knowing whether the form is secure, the only option is to create forms that use no script when you want to use the form in a system that requires digital signatures. One problem with disabling scripting in documents that have archival or security requirements is that the scripting is how such documents provide dynamic behaviors that yield a rich user experience. The problem is acute because some fairly straightforward features require a dynamic document, such as inserting or deleting a row from a purchase order, providing a wizard-like guided interview experience, changing the colors or visibility of user interface controls based on user events or user input, and even presenting information that is the calculated or aggregate result of other user input.
Historically, the Workplace Forms product has attempted to address this problem by virtue of XFDL being an XML format in which the results of all calculations and dynamic changes are stored in the markup so that the document serialization represents a snapshot of not just a forms application but the application state. Having everything recorded in the document XML means that dynamic behaviors can be preserved while still satisfying security and archival requirements. However, the introduction of XForms into XFDL has caused the language to become more like other document formats in the sense that the presentation layer is an ephemeral template whose serialization does not directly reflect dynamic changes made during run time. Instead, with XForms, the only thing that changes during user interaction is the XML data in the model.
In view of the foregoing, there exits a need for a solution that overcomes at least one of the deficiencies in the related art.